%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright (C) Olaf Kirch, okir@monad.swb.de  %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%               S T A R T   O F   C H A P T E R                 %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Various Network Applications}
\label{appl}

After successfully setting up IP and the resolver, you have to turn to
the services you want to provide over the network. This chapter covers
the configuration of a few simple network applications, including the
\prog{inetd} server, and the programs from the \prog{rlogin} family.
The Remote Procedure Call interface that services like the Network File
System (NFS) and the Network Information System (NIS) are based upon
will be dealt with briefly, too. The configuration of NFS and NIS,
however, takes up more room, will be described in separate chapters.
This applies to electronic mail and netnews as well.


Of course, we can't cover all network applications in this book. If you
want to install one that's not discussed here, like \prog{talk},
\prog{gopher}, or \prog{Xmosaic} please refer to its manual pages for
details.


\section{The \prog{inetd} Super-Server}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{appl.inetd}
\index{inetd@\prog{inetd}}
\index{services!setting up}
\index{server!inetd@\prog{inetd}|(}
\index{configuring!network services}

Frequently, services are performed by so-called \emph{daemons}. A daemon
is a program that opens a certain port, and waits for incoming
connections.  If one occurs, it creates a child process which accepts
the connection, while the parent continues to listen for further
requests.  This concept has the drawback that for every service offered,
a daemon has to run that listens on the port for a connection to occur,
which generally means a waste of system resources like swap space.


Thus, almost all \unix{} installations run a ``super-server'' that
creates sockets for a number of services, and listens on all of them
simultaneously using the \func{select(2)} system call. When a remote
host requests one of the services, the super-server notices this and
spawns the server specified for this port.


\index{inetd.conf@\file{inetd.conf}|(}
\index{chargen@\prog{chargen}}
\index{daytime@\prog{daytime}}
The super-server commonly used is \prog{inetd}, the Internet Daemon.
It is started at system boot time, and takes the list of services it
is to manage from a startup file named \file{/etc/inetd.conf}.  In
addition to those servers invoked, there are a number of trivial
services which are performed by \prog{inetd} itself called \emph{internal
services}. They include \prog{chargen} which simply generates a string of
characters, and \prog{daytime} which returns the system's idea of the time
of day.


An entry in this file consists of a single line made up of the
following fields:


\begin{tscreen}
\var{service type protocol wait user server cmdline}
\end{tscreen}


\noindent
The meaning of each field is as follows:

\begin{dispitems}
\ditem[\var{service}]
        \index{services@\file{services}}
        gives the service name. The service name has to be translated to
        a port number by looking it up in the \file{/etc/services} file.
        This file will be described in section \ref{appl.services}
        below.

\ditem[\var{type}]
        specifies a socket type, either \keyword{stream} (for
        connection-oriented protocols) or \keyword{dgram} (for datagram
        protocols).  TCP-based services should therefore always use
        \keyword{stream}, while UDP-based services should always use
        \keyword{dgram}.

\ditem[\var{protocol}]
        \index{protocols@\file{protocols}}
        names the transport protocol used by the service. This must be a
        valid protocol name found in the \file{protocols} file, also
        explained below.

\ditem[\var{wait}]
        This option applies only to \keyword{dgram} sockets. It may
        be either \keyword{wait} or \keyword{nowait}. If \keyword{wait} is
        specified, \prog{inetd} will only execute one server for
        the specified port at any time. Otherwise, it will immediately
        continue to listen on the port after executing the server.

        This is useful for ``single-threaded'' servers that read all
        incoming datagrams until no more arrive, and then exit. Most RPC
        servers are of this type and should therefore specify
        \keyword{wait}.  The opposite type, ``multi-threaded'' servers,
        allow an unlimited number of instances to run concurrently; this
        is only rarely used. These servers should specify
        \keyword{nowait}.

        \keyword{stream} sockets should always use \keyword{nowait}.

\ditem[\var{user}]
        This is the login id of the user the process is executed under.
        This will frequently be the \user{root} user, but some services
        may use different accounts. It is a very good idea to apply the
        principle of least privilege here, which states that you shouldn't
        run a command under a privileged account if the program doesn't
        require this for proper functioning.
        For example, the NNTP news server will run as \user{news}, while
        services that may pose a security risk (such as \prog{tftp} or
        \prog{finger}) are often run as \user{nobody}.

\ditem[\var{server}]
        gives the full path name of the server program to be executed.
        Internal services are marked by the keyword \keyword{internal}.

\ditem[\var{cmdline}]
        This is the command line to be passed to the server. This includes
        argument~0, that is the command name. Usually, this will be
        the program name of the server, unless the program behaves
        differently when invoked by a different name.

        This field is empty for internal services.

\end{dispitems}


\begin{figure}[hbtp]
\begin{tscreen}
\begin{verbatim}
# 
# inetd services
ftp       stream tcp nowait root   /usr/sbin/ftpd    in.ftpd -l
telnet    stream tcp nowait root   /usr/sbin/telnetd in.telnetd -b/etc/issue
#finger    stream tcp nowait bin    /usr/sbin/fingerd in.fingerd
#tftp      dgram  udp wait   nobody /usr/sbin/tftpd   in.tftpd
#tftp      dgram  udp wait   nobody /usr/sbin/tftpd   in.tftpd /boot/diskless
login     stream tcp nowait root   /usr/sbin/rlogind in.rlogind
shell     stream tcp nowait root   /usr/sbin/rshd    in.rshd
exec      stream tcp nowait root   /usr/sbin/rexecd  in.rexecd
#
#       inetd internal services
#
daytime   stream tcp nowait root internal
daytime   dgram  udp nowait root internal
time      stream tcp nowait root internal
time      dgram  udp nowait root internal
echo      stream tcp nowait root internal
echo      dgram  udp nowait root internal
discard   stream tcp nowait root internal
discard   dgram  udp nowait root internal
chargen   stream tcp nowait root internal
chargen   dgram  udp nowait root internal
\end{verbatim}
\end{tscreen}
 \caption{
  \label{appl.fig.inetd.conf}
  A sample \file{/etc/inetd.conf} file.
 }
\end{figure}


\index{security!TCP servers}
\index{finger@\prog{finger}}
A sample \file{inetd.conf} file is shown in figure~\ref{appl.fig.inetd.conf}.
The \prog{finger} service commented out, so that it is not available.
This is often done for security reasons, because may be used by
attackers to obtain names of users on your system.


\index{TFTP|see {Trivial File Transfer Protocol}}
\index{Trivial File Transfer Protocol}
\index{tftp@\prog{tftp}}
The \prog{tftp} is shown commented out as well. \prog{tftp} implements
the \emph{Primitive File Transfer Protocol} that allows to transfer any
world-readable files from your system without password checking etc.
This is especially harmful with the \file{/etc/passwd} file, even more
so when you don't use shadow password.


TFTP is commonly used by diskless clients and X~terminals to download
their code from a boot server. If you need to run \prog{tftpd} for this
reason, make sure to limit its scope to those directories clients will
retrieve files from by adding those directory names to \prog{tftpd}'s
command line. This is shown in the second \prog{tftp} line in the
example.

\index{inetd.conf@\file{inetd.conf}|)}


\section{The \prog{tcpd} access control facility}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{appl.tcpd}
\index{security!TCP servers}
\index{services!restricting access}
\index{access!restricting}
\index{restricting access}
\index{wrapper, TCP}
\index{TCP!wrapper program}
\index{tcpd@\prog{tcpd}|(}
\index{server!inetd@\prog{tcpd}|(}

Since opening a computer to network access involves many security risks,
applications are designed to guard against several types of attacks.
Some of these, however, may be flawed (most drastically demonstrated
by the RTM Internet worm), or do not distinguish between secure hosts
from which requests for a particular service will be accepted, and
insecure hosts whose requests should be rejected. We already briefly
discussed the \prog{finger} and \prog{tftp} services above.  Thus, one
would want to limit access to these services to ``trusted hosts'' only,
which is impossible with the usual setup, where \prog{inetd} either
provides this service to all clients, or not at all.


A useful tool for this is \prog{tcpd},\footnote{
  Written by Wietse Venema, \email{wietse@wzv.win.tue.nl}.
} a so-called daemon wrapper. For TCP services you want to monitor or
protect, it is invoked instead of the server program. \prog{tcpd} logs
the request to the \prog{syslog} daemon, ckecks if the remote host is
allowed to use that service, and only if this succeeds will it executes
the real server program. Note that this does not work with UDP-based
services.


For example, to wrap the \prog{finger} daemon, you have to change the
corresponding line in \file{inetd.conf} to


\begin{tscreen}
\begin{verbatim}
# wrap finger daemon
finger  stream  tcp     nowait  root    /usr/sbin/tcpd   in.fingerd
\end{verbatim}
\end{tscreen}


\index{syslog@\prog{syslog}}
Without adding any access control, this will appear to the client
just as a usual \prog{finger} setup, except that any requests are logged
to \prog{syslog}'s \keyword{auth} facility.


Access control is implemented by means of two files called
\file{/etc/hosts.allow} and \file{/etc/hosts.deny}.  They contain
entries allowing and denying access, respectively, to certain services
and hosts.  When \prog{tcpd} handles a request for a service such as
\prog{finger} from a client host named \host{biff.foobar.com}, it
scans \file{hosts.allow} and \file{hosts.deny} (in this order) for an
entry matching both the service and client host. If a matching entry
is found in \file{hosts.allow}, access is granted, regardless of any
entry in \file{hosts.deny}. If a match is found in \file{hosts.deny},
the request is rejected by closing down the connection. If no match is
found at all, the request is accepted.


Entries in the access files look like this:

\begin{tscreen}
 \var{servicelist}: \var{hostlist} [:\var{shellcmd}\/]
\end{tscreen}

%\indent
%These field have the following meaning:
%
%\begin{dispitems}

\var{servicelist} is a list of service names from \file{/etc/services},
or the keyword \keyword{ALL}. To match all services except \prog{finger} and
\prog{tftp}, use ``\keyword{ALL} \keyword{EXCEPT} \prog{finger, tftp}''.


\var{hostlist} is a list of host names or IP~addresses, or the keywords
\keyword{ALL}, \keyword{LOCAL}, or \keyword{UNKNOWN}. \keyword{ALL} matches any host,
while \keyword{LOCAL} matches host names not containing a dot.\footnote{
 Usually only local host names obtained from lookups in \file{/etc/hosts}
 contain no dots.
} \keyword{UNKNOWN} matches any hosts whose name or address lookup failed.
A name starting with a dot matches all hosts whose domain is equal to this
name. For example, \host{.foobar.com} matches \host{biff.foobar.com}.
There are also provisions for IP~network addresses and subnet numbers.
Please refer to the \file{hosts\_access(5)} manual page for details.


To deny access to the \prog{finger} and \prog{tftp} services to all but
the local hosts, put the following in \file{/etc/hosts.deny}, and leave
\file{/etc/hosts.allow} empty:


\begin{tscreen}
in.tftpd, in.fingerd: ALL EXCEPT LOCAL, \var{.your.domain}
\end{tscreen}


The optional \var{shellcmd} field may contain a shell command
to be invoked when the entry is matched. This is useful to set up
traps that may expose potential attackers:

\begin{tscreen}
\begin{verbatim}
in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \
      echo "request from %d@%h" >> /var/log/finger.log; \
      if [ %h != "vlager.vbrew.com" ]; then \
          finger -l @%h >> /var/log/finger.log \
      fi
\end{verbatim}
\end{tscreen}

The \keyword{\%h} and \keyword{\%d} arguments are expanded by \prog{tcpd}
to the client host name and service name, respectively. Please refer to the
\file{hosts\_access(5)} manual page for details.


\index{tcpd@\prog{tcpd}|)}
\index{server!inetd@\prog{tcpd}|)}
\index{server!inetd@\prog{inetd}|)}

%\end{dispitems}

\section{The \file{services} and \file{protocols} Files}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{appl.services}{The \file{services} and \file{protocols} Files}
\namedlabel{appl.protocols}{The \file{services} and \file{protocols} Files}
\index{services@\file{services}|(}
\index{protocols@\file{protocols}|(}
\index{services!well-known}

The port numbers on which certain ``standard'' services are offered are
defined in the ``Assigned Numbers'' RFC. To enable server and client
programs to convert service names to these numbers, at least a part of
the list is kept on each host; it is stored in a file called
\file{/etc/services}.  An entry is made up like this:


\begin{tscreen}
\var{service} \var{port}/\var{protocol}   [\var{aliases}]
\end{tscreen}


Here, \var{service} specifies the service name, \var{port} defines the
port the service is offered on, and \var{protocol} defines which
transport protocol is used. Commonly, this is either \keyword{udp} or
\keyword{tcp}. It is possible for a service to be offered for more
than one protocol, as well as offering different services on the same
port, as long as the protocols are different. The \var{aliases} field
allows to specify alternative names for the same service.


Usually, you don't have to change the services file that comes along
with the network software on your \linux{} system. Nevertheless, we
give a small excerpt from that file below.


\begin{tscreen}
\begin{verbatim}
# The services file:
#
# well-known services
echo           7/tcp                 # Echo
echo           7/udp                 #
discard        9/tcp  sink null      # Discard
discard        9/udp  sink null      #
daytime       13/tcp                 # Daytime
daytime       13/udp                 #
chargen       19/tcp  ttytst source  # Character Generator
chargen       19/udp  ttytst source  #
ftp-data      20/tcp                 # File Transfer Protocol (Data)
ftp           21/tcp                 # File Transfer Protocol (Control)
telnet        23/tcp                 # Virtual Terminal Protocol
smtp          25/tcp                 # Simple Mail Transfer Protocol
nntp         119/tcp  readnews       # Network News Transfer Protocol
#
# UNIX services
exec         512/tcp                 # BSD rexecd
biff         512/udp  comsat         # mail notification
login        513/tcp                 # remote login
who          513/udp  whod           # remote who and uptime
shell        514/tcp  cmd            # remote command, no passwd used
syslog       514/udp                 # remote system logging
printer      515/tcp  spooler        # remote print spooling
route        520/udp  router routed  # routing information protocol
\end{verbatim}
\end{tscreen}


Note that, for example, the \prog{echo} service is offered on
port 7 for both TCP and UDP, and that port 512 is used for two different
services, namely the COMSAT daemon (which notifies users of newly
arrived mail, see \prog{xbiff(1x)}), over UDP, and for remote
execution (\prog{rexec(1)}), using TCP.


\index{protocol numbers}
Similar to the services file, the networking library needs a way to
translate protocol names~--- for example, those used in the services
file~--- to protocol numbers understood by the IP layer on other hosts.
This is done by looking up the name in the \file{/etc/protocols} file.
It contains one entry per line, each containing a protocol name, and the
associated number. Having to touch this file is even more unlikely than
having to meddle with \file{/etc/services}. A sample file is given 
below:


\begin{tscreen}
\begin{verbatim}
#
# Internet (IP) protocols
#
ip      0       IP              # internet protocol, pseudo protocol number
icmp    1       ICMP            # internet control message protocol
igmp    2       IGMP            # internet group multicast protocol
tcp     6       TCP             # transmission control protocol
udp     17      UDP             # user datagram protocol
raw     255     RAW             # RAW IP interface
\end{verbatim}
\end{tscreen}

\index{services@\file{services}|)}
\index{protocols@\file{protocols}|)}


\section{Remote Procedure Call}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{appl.rpc}{Remote Procedure Call}
\index{Remote Procedure Call|(}
\index{RPC|see {Remote Procedure Call}}

A very general mechanism for client-server applications is provided by
RPC, the \emph{Remote Procedure Call} package. RPC was developed by Sun
Micrsystems, and is a collection of tools and library functions.
Important applications built on top of RPC are NFS, the Network
Filesystem, and NIS, the Network Information System, both of which will
be introduced in later chapters.


\index{External Data Representation}
\index{XDR|see {External Data Representation}}
An RPC server consists of a collection of procedures that client may
call by sending an RPC request to the server, along with the procedure
parameters. The server will invoke the indicated procedure on behalf of
the client, handing back the return value, if there is any.  In order to
be machine-independent, all data exchanged between client and server is
converted to a so-called \emph{External Data Representation} format (XDR)
by the sender, and converted back to the machine-local representation by
the receiver.


Sometimes, improvements to an RPC application introduce incompatible
changes in the procedure call interface. Of course, simply changing the
server would crash all application that still expect the original
behavior.  Therefore, RPC programs have version numbers assigned to
them, usually starting with~1, and with each new version of the RPC
interface this counter will be bumped. Often, a server may offer several
versions simultaneously; clients then indicate by the version number in
their requests which implementation of the service they want to use.


\index{rpc@\file{rpc}}
\index{Remote Procedure Call!program numbers}
The network communication between RPC servers and clients is somewhat
peculiar. An RPC server offers one or more collections of procedures;
each set is being called a \emph{program}, and is uniquely identified
by a \emph{program number}. A list mapping service names to program numbers
is usually kept in \file{/etc/rpc}, an excerpt of which is reproduced below
in figure~\ref{rpc.fig}.


\begin{figure}[htbp]
\begin{tscreen}
\begin{verbatim}
#
# /etc/rpc - miscellaenous RPC-based services
#
portmapper      100000  portmap sunrpc
rstatd          100001  rstat rstat_svc rup perfmeter
rusersd         100002  rusers
nfs             100003  nfsprog
ypserv          100004  ypprog
mountd          100005  mount showmount
ypbind          100007
walld           100008  rwall shutdown
yppasswdd       100009  yppasswd
bootparam       100026
ypupdated       100028  ypupdate
\end{verbatim}
\end{tscreen}
 \caption{
  \label{rpc.fig}
  A sample \file{/etc/rpc} file.
 }
\end{figure}


In TCP/IP networks, the authors of RPC were faced with  the problem of
mapping program numbers to generic network services. They
chose to have each server provide both a TCP and a UDP port for each
program and each version. Generally, RPC applications will use UDP when
sending data, and only fall back to TCP when the data to be transferred
doesn't fit into a single UDP datagram.


\index{portmapper daemon}
\index{Remote Procedure Call!mapping ports to programs}
\index{portmap@\prog{portmap}}
Of course, client programs have to have a way to find out which port
a program number maps to. Using a configuration file for this would be
too unflexible; since RPC applications don't use reserved ports, there's
no guarantee that a port originally meant to be used by our database
application hasn't been taken by some other process. Therefore, RPC
applications pick any port they can get, and register it with the so-called
\emph{portmapper daemon}. The latter acts as a service broker for all
RPC servers running on its machine: a client that wishes to contact
a service with a given program number will first query the portmapper
on the server's host which returns the TCP and UDP port numbers the
service can be reached at.


\index{inetd@\prog{inetd}}
This method has the particular drawback that it introduces a single point
of failure, much like the \prog{inetd} daemon does for the standard
Berkeley services. However, this case is even a little worse, because
when the portmapper dies, all RPC port information is lost; this
usually means you have to restart all RPC servers manually, or reboot
the entire machine.


On \linux{}, the portmapper is called \prog{rpc.portmap} and resides
in \file{/usr/sbin}. Other than making sure it is started form
\prog{rc.inet2}, the portmapper doesn't require any configuration work.

\index{Remote Procedure Call|)}


\section{Configuring the \prog{r} Commands}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{appl.remote}
\index{configuring!the r commands@the \prog{r} commands|(}
\index{authorization!and r commands@and \prog{r} commands}
\index{LAN!r commands@\prog{r} commands}
\index{LAN!passwords}
\index{passwords!and remote login}
\index{remote!command execution}
\index{security!r commands@\prog{r} commands}
\index{security!remote login}
\index{remote!login}
\index{remote!file access}
\index{rlogin@\prog{rlogin}}
\index{rcp@\prog{rcp}}
\index{rsh@\prog{rsh}}

There are a number of commands for executing commands on remote
hosts. These are \prog{rlogin}, \prog{rsh}, \prog{rcp} and \prog{rcmd}.
They all spawn a shell on the remote host and allow the user
to execute commands. Of course, the client needs to have an account
on the host where the commmand is to be executed. Thus all these commands
perform an authorization procedure. Usually, the client will tell
the user's login name to the server, which in turn requests a password
that is validated in the usual way.


Sometimes, however, it is desirable to relax authorization checks for
certain users.  For instance, if you frequently have to log into other
machines on your LAN, you might want to be admitted without having to
type your password every time.
% On one hand, this is a question of convenience, on the other it may be
% a matter of security not having to send your password across an insecure
% network every time you log in.


Disabling authorization is advisable only on a small number of hosts
whose password databases are synchronized, or for a small number of
privileged users who need to access many machines for administrative
reasons. Whenever you want to allow people to log into your host without
having to specify a login id or password, make sure that you don't
accidentally grant access to anybody else.


\index{hosts.equiv@\file{hosts.equiv}}
\index{rhosts@\file{.rhosts}}
There are two ways to disable authorization checks for the \file{r}
commands. One is for the super user to allow certain or all
users on certain or all hosts (the latter definitely being a bad
idea) to log in without being asked for a password. This access
is controlled by a file called \file{/etc/hosts.equiv}. It contains
a list of host and user names that are considered equivalent to users
on the local host.  An alternative option is for a user to grant other
users on certain hosts access to her account. These may be listed in the
file \file{.rhosts} in the user's home directory. For security reasons,
this file must be owned by the user or the super user, and must not be a
symbolic link, otherwise it will be ignored.\footnote{
 In an NFS environment, you may need to give it a protection of 444,
 because the super user is often very restricted in accessing files on
 disks mounted via NFS.
}


When a client requests an \prog{r} service, her host and user name are
searched in the \file{/etc/hosts.equiv} file, and then in the
\file{.rhosts} file of the user she wants to log in as. As am example,
assume \user{janet} is working on \host{gauss} and tries to log into
\user{joe}'s account on \host{euler}. Throughout the following, we will
refer to Janet as the \emph{client} user, and to Joe as the \emph{local}
user.  Now, when Janet types

\begin{tscreen}
\$ rlogin -l joe euler
\end{tscreen}

\noindent
on \host{gauss}, the server will first check \file{hosts.equiv}\footnote{
 Note that the \file{hosts.equiv} file is \emph{not}
 searched when someone attempts to log in as \user{root}.
} if Janet should be granted free access, and if this fails,
it will try to look her up in \file{.rhosts} in \user{joe}'s home directory.


The \file{hosts.equiv} file on \host{euler} looks like this:

\begin{tscreen}
\begin{verbatim}
gauss
euler
-public
quark.physics.groucho.edu     andres
\end{verbatim}
\end{tscreen}

An entry consists of a host name, optionally followed by a user name.
If a host name appears all by itself, all users from that host will be
admitted to their local accounts without any checks. In the above
example, Janet would be allowed to log into her account \user{janet}
when coming from \host{gauss}, and the same applies to any other user
except \user{root}. However, if Janet wants to log in as \user{joe},
she will be prompted for a password as usual.


If a host name is followed by a user name, as in the last line of the
above sample file, this user is given password-free access to \emph{all}
accounts except the \user{root} account.


The host name may also be preceded by a minus sign, as in the entry
``\host{-public}''. This requires authorization for all accounts on
\host{public}, regardless of what rights individual users grant in their
\file{.rhosts} file.


The format of the \file{.rhosts} file is identical to that of
\file{hosts.equiv}, but its meaning is  a little different. Consider
Joe's \file{.rhosts} file on \host{euler}:


\begin{tscreen}\small
\begin{verbatim}
chomp.cs.groucho.edu
gauss      janet
\end{verbatim}
\end{tscreen}


The first entry grants \user{joe} free acess when logging in from
\host{chomp.cs.groucho.edu}, but does not affect the rights of any other
account on \host{euler} or \host{chomp}. The second entry is a slight
variation of this, in that it grants \user{janet} free access to Joe's
account when logging in from \host{gauss}.


Note that the client's host name is obtained by reverse mapping the
caller's address to a name, so that this feature will fail with hosts
unknown to the resolver. The client's host name is considered to match
the name in the hosts files in one of the following cases:


\begin{itemize}
\item   The client's canonical host name (not an alias) literally
        matches the host name in the file.

\item   If the client's host name is a fully qualified domain name (such
        as returned by the resolver when you have DNS running), and it
        doesn't literally match the host name in the hosts file, it is
        compared to that host name expanded with the local domain name.

% \item   The host name specified in the hosts file is \host{+},
%         in which case any host name matches.
\end{itemize}


% If NIS is in place, the hosts files provide yet another feature.
% Instead of a host or user name, a netgroup (as defined in the
% \file{/etc/netgroups} file) may be specified, preceded by an at sign
% (@).
% 
% If the netgroup appears instead of a host name, the entry applies to
% all hosts in the netgroup; if it appears instead of a user name, the
% entry applies to all users in the netgroup.
% 
% 
% If the netgroup name is preceded by a plus, the entry grants free
% access to all clients matching the entry; otherwise it denies access.
% 

\index{configuring!the r commands@the \prog{r} commands|)}



 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%
%% We don't really want this. The BSD ftpd doesn't really cut it
%% as an FTP server, and wu-ftpd is way too complicated to cram it
%% into two and a half pages.
%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \section{Setting up an FTP Server}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{appl.ftp}
% \index{configuring!anonymous FTP|(}
% \index{FTP, anonymous|(}
% \index{server!ftpd@\prog{ftpd}}
% \index{ftpd@\prog{ftpd}}
% \index{passwd@\file{passwd}}
% \index{shadow@\file{shadow}}
% 
% 
% The most widely known use of FTP (File Transfer Protocol) is to
% provide users from any host with access to publicly available data.
% This is generally called anonymous FTP. However, it may be used
% for file transfers from and to local user accounts as well. The FTP
% server, \prog{ftpd}, performs the usual authorization procedure using
% the \file{/etc/passwd} and \file{/etc/shadow} databases.
% 
% 
% \index{ftpusers@\file{ftpusers}}
% \index{access!restricting}
% After passing this procedure, a client is allowed access to any files
% and directories accessible to the user she logged in as.  Certain users
% may be denied access to FTP by listing them in the file
% \file{/etc/ftpusers}. This file contains one user name per line, without
% any white space allowed.
% 
% 
% There are other FTP daemons, e.g. \prog{ftpd-diku}, which have enhanced
% functionality.  Since they are not part of the ``official'' networking
% release, I do not describe them here. Please refer to the documentation
% that comes with them.
% 
% 
% \subsection{Anonymous FTP}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{appl.ftp.anonymous}
% 
% Anonymous FTP requires tough security measures to prevent clients from
% accessing any important information on your system.
% 
% 
% To set up an anonymous FTP account, you have to create a user named
% \user{ftp}. It should be member of a group with very limited access only,
% for example \user{guest}, have a login shell of \prog{/bin/false}, and a
% password of ``\keyword{*}'' to prevent anyone from actually logging in as
% \user{ftp}. The home directory should be something like \file{/home/ftp},
% have proper ownership (namely \user{ftp} and \user{guest}) and have a
% protection mode of 555. The entry in the \file{passwd} file would look like
% this:
% 
% \begin{tscreen}
% \begin{verbatim}
% ftp:*:500:60:Anonymous FTP:/home/ftp:/bin/false
% \end{verbatim}
% \end{tscreen}
% 
% 
% If a client specifies a user name of \user{ftp} or \user{anonymous} when
% asked by \prog{ftpd}, the server performs a \func{chroot(2)} to the
% home directory of the \user{ftp} account. The effect of this is that this
% home directory appears to the client as the root of the directory hierarchy,
% thus denying it access to any files outside the home directory.\footnote{
%  When you merely change the working directory, you may access files
%  outside of it by either using absolute pathnames or \file{..} to move
%  up the directory hierarchy.  When doing a \prog{chroot}, all absolute
%  pathnames are interpreted as starting at the new directory, and its
%  parent directory is inaccessible.
% } Any files (such as the \prog{ls} command) accessed after this \prog{chroot}
% must thus be available beneath this directory.
% 
% 
% In addition, you may allow sub-logins of users whom you have granted
% special access to your FTP area, for example the person who maintains
% the \file{Network} directory. These users first log in as an anonymous
% FTP user, and after that log into the sub-account by specifying a user
% name and password using the \keyword{USER} command of \prog{ftp}. For
% these, you have to set up a home directory, which is owned by the user
% and has mode 700. Remember that the home directory name is rooted
% at \user{ftp}'s home directory.
% 
% 
% \noindent
% The following files directories need to be present:
% 
% \begin{dispitems}
% \ditem[\file{\tld{}ftp/bin}]
%         This directory should be owned by \user{root} and have mode
%         555.  It should contain a copy of the \prog{ls} command, which
%         is needed by \prog{ftpd} to list directories. It should be
%         mode 111.  If \file{\tld{}ftp} is on the same file system as
%         \file{/bin}, this may also be a hard link to \file{/bin/ls};
%         however, you can not make it a symbolic link.
% 
% \ditem[\file{\tld{}ftp/lib}]
%         This directory should be owned by \user{root} and have mode 555.
%         If the programs in \file{\tld ftp/bin} are dynamically linked, it
%         must contain a copy of the current version of the shared C~library,
%         \file{/lib/libc.so.\var X}, and the dynamic loader \file{ld.so}.
%         Most \linux{} distributions, however, contain a statically linked
%         \prog{ls} binary for this FTP purpose, so you don't need the shared
%         library in \file{\tld ftp/lib}.
% 
% \ditem[\file{\tld{}ftp/etc}]
% 	\index{passwd@\file{passwd}}
% 	\index{shadow@\file{shadow}}
%         This directory should be owned by \user{root} and have mode 555.
%         It should contain a \file{passwd} and \file{group} file to
%         map user id's to login names when listing files. They should not
%         be complete copies of the files from \file{/etc}, nor should
%         they be hard links, since this would provide intruders with a
%         list of all accounts on your system.
% 
%         The \file{passwd} and \file{shadow} files should contain data
%         for \user{root}, \user{bin}, \user{ftp}, plus the available
%         sub-logins.
% 
%         Accounts other than sub-logins should be denied access by
%         specifying a password of ``\keyword{*}'' in the password
%         field.
% 
% \ditem[\file{\tld{}ftp/incoming}]
%         This directory should be owned by \user{ftp}. It should have
%         mode 1733 to allow users to deposit files, but prevent others
%         from retrieving them before you have moved them to the proper
%         location (or thrown them away, for that matter).  Alternatively,
%         it can have mode 1777 if you want to allow them to be retrieved.
% 
% \ditem[\file{\tld{}ftp/pub}]
%         Below this directory, you keep all files you want to make
%         available to users of your anonymous FTP service. The directory
%         should be owned by \user{ftp} and have mode 555. Files below this
%         should have mode 444 to prevent FTP users from removing or
%         modifying them.
% 
% \end{dispitems}
% 
% If your \file{\tld{}ftp/} directory is not on the same partition as your
% shared libraries, you will almost certainly be better off to make
% staticly linked copies of your executables, as the shared library is
% quite large, and would take up more disk space than simply making a few
% staticly-linked executables.  Another possibility is installing the
% ``lite'' shared library, which is available in the GCC/library
% distribution, and is quite a bit smaller.
% 
% 
% 
% \subsection{\prog{ftpd} Options}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{appl.ftp.options}
% \index{inetd.conf@\file{inetd.conf}}
% \index{inetd@\prog{inetd}}
% \index{ftpd@\prog{ftpd}}
% 
% Usually, \prog{ftpd} is invoked by the \prog{inetd} super-server. On the
% command line passed to \prog{ftpd}, you may specify the following
% options:
% 
% 
% \begin{dispitems}
% \ditem[\option{-l}]
%         Log FTP sessions.
% 
% \ditem[\option{-d \var{dbglvl}}]
%         Log debug messages. 
% 
% \ditem[\option{-t \var{timeout}}]
%         Causes \prog{ftpd} to close down sessions after the client has
%         been inactive for the specified amount of time. By default, this
%         value is set to 15 minutes.
% 
% \ditem[\option{-u \var{umask}}]
%         Sets the file creation mask used by \prog{ftpd} to \var{umask}.
%         It defaults to 027, which means that files deposited in the
%         \file{incoming} directory will have a permission of 640.
% 
% \end{dispitems}
% 
% You can add these options to the \prog{ftpd} invocation in \file{inetd.conf}.
% 
% 
% \index{syslog@\prog{syslog}}
% When logging is enabled, \prog{ftpd} logs messages to the
% \keyword{daemon} facility of \prog{syslogd}. FTP sessions are logged at
% the \keyword{info} level; debug messages are logged at the
% \keyword{debug} level. To send these messages to a file, enter the
% following line to \file{/etc/syslogd.conf}:
% 
% 
% \begin{tscreen}
% \begin{verbatim}
% daemon.info:    /usr/adm/daemon.log
% \end{verbatim}
% \end{tscreen}
% 
% \index{configuring!anonymous FTP|)}
% \index{FTP, anonymous|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                E N D   O F   C H A P T E R                    %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
